docs/guides/authentication/lucia.md (3)

7-11: Enhance the deprecation notice with migration guidance.

While the deprecation notice is clear, it would be more helpful to provide guidance on recommended alternatives for authentication. Consider adding information about preferred authentication solutions (e.g., Auth.js) and potential migration paths.

 # Integrating With Lucia (Deprecated)

 :::info
-Lucia's is [not in active development anymore](https://github.com/lucia-auth/lucia/discussions/1714).
+Lucia is [no longer in active development](https://github.com/lucia-auth/lucia/discussions/1714). We recommend using [Auth.js](./auth-js) for new projects. For migration guidance, please refer to our [migration guide](../migrations/lucia-to-authjs).
 :::

---

Line range hint 13-24: Consider adding a maintenance status banner.

While the technical content remains accurate, it would be helpful to add a prominent notice at the top of each major section indicating that while this integration still works, it's in maintenance mode and won't receive future updates. This helps users make informed decisions when implementing authentication in their projects.

+:::note
+While this integration remains functional, it is in maintenance mode and won't receive future updates. Consider using our actively maintained authentication solutions for new projects.
+:::

[Lucia](https://lucia-auth.com/) is an auth library for your server that abstracts away the complexity of handling sessions...

---

10-10: Fix typo in deprecation notice.

There's a grammatical error in the deprecation notice.

-Lucia's is [not in active development anymore](https://github.com/lucia-auth/lucia/discussions/1714).
+Lucia is [not in active development anymore](https://github.com/lucia-auth/lucia/discussions/1714).

docs/guides/typing-json.md (6)

6-16: Enhance the Preview feature documentation.

Consider adding:

• A note explaining what "Preview" means for users (e.g., API stability, production readiness)
• The minimum version of ZenStack required for this feature

---

47-49: Provide more context about type inheritance limitations.

Consider expanding on:

• Why inheritance isn't supported yet
• What kind of inheritance will be supported in future releases
• Any workarounds available in the meantime

---

64-68: Expand @JSON attribute documentation.

Consider adding:

• Available options/parameters for the @JSON attribute
• Whether it supports arrays or nested objects
• Any performance implications

---

74-78: Clarify import path in the example.

The import path ~/db is project-specific. Consider:

• Using a more generic import path
• Adding a note about how to set up the database client

-import { prisma } from '~/db';
+import { PrismaClient } from '@prisma/client';
+
+const prisma = new PrismaClient();

---

125-171: Enhance validation examples and error handling guidance.

Consider adding:

• More complex validation scenarios (e.g., conditional validation, custom validators)
• Best practices for handling validation errors in production
• Examples of custom error messages

---

172-198: Expand TypeScript and Zod integration examples.

Consider adding:

• Advanced usage patterns (e.g., type inference, partial types)
• Integration examples with popular form libraries (e.g., React Hook Form, Formik)
• Error handling patterns with Zod schemas

docs/reference/zmodel-language.md (4)

26-33: Consider adding details about multi-schema files support.

While the addition of multi-schema files support to the list is valuable, it would be helpful to add a dedicated section or subsection explaining this feature, including:

• How to use multiple schema files
• Best practices for organizing schemas across files
• Limitations or considerations when using multiple files

🧰 Tools

🪛 LanguageTool

[style] ~26-~26: Consider replacing this phrase with the adverb “naturally” to avoid wordiness.
Context: ...us to build the functionalities we want in a natural way, so we made several extensions to the l...

(IN_A_X_MANNER)

---

290-332: LGTM! Well-structured Type documentation.

The Type construct documentation is comprehensive and well-organized. It effectively covers the purpose, syntax, use cases, and limitations. The example effectively demonstrates the @JSON attribute usage.

Consider adding a "See also" section at the end to link to related topics like JSON field typing guide and @JSON attribute documentation for better navigation.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~307-~307: You might be missing the article “the” here.
Context: ...Needs to be a valid identifier matching regular expression [A-Za-z][a-za-z0-9_]\*. -...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

---

Line range hint 1160-1184: Enhance field documentation to clarify model vs. type fields.

While the documentation now correctly covers fields in both models and types, consider adding:

1. A comparison table or section highlighting differences between model fields and type fields
2. Specific constraints or behaviors unique to each context
3. Examples showing field usage in both models and types

🧰 Tools

🪛 LanguageTool

[uncategorized] ~1180-~1180: You might be missing the article “the” here.
Context: ...Needs to be a valid identifier matching regular expression [A-Za-z][a-za-z0-9_]\*. -...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

---

[style] ~1184-~1184: To form a complete sentence, be sure to include a subject or ‘there’.
Context: ...*[FIELD_TYPE]** Type of the field. Can be a scalar type, a reference to anothe...

(MISSING_IT_THERE)

---

699-706: Add more examples for @JSON attribute usage.

The @JSON attribute documentation is clear but could be enhanced with:

1. Multiple examples showing different use cases
2. Common patterns and best practices
3. Examples of how the attribute affects the generated Prisma Client types

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify the referenced sample repository branch

# Test: Check if the branch exists and contains edge runtime configuration
gh repo clone zenstackhq/sample-todo-nextjs-tanstack
cd sample-todo-nextjs-tanstack
git checkout v2-edge
rg -l "runtime.*=.*'edge'"

#!/bin/bash
# Description: Check if the referenced Prisma documentation URLs are valid

# Test: Extract and verify URLs
curl -s -o /dev/null -w "%{http_code}" https://www.prisma.io/docs/accelerate
curl -s -o /dev/null -w "%{http_code}" https://www.prisma.io/docs/orm/prisma-client/deployment/edge/overview

#!/bin/bash
# Description: Check for any updates regarding D1 database support

# Test 1: Check for D1-related issues or discussions
gh issue list --repo zenstackhq/zenstack --search "D1 database" --state all --limit 5

# Test 2: Check for any D1-related code or documentation
rg -i "cloudflare.*d1|d1.*database"

#!/bin/bash
# Check for any recent commits or changes related to D1 database support
git log --since="6 months ago" -i --grep="d1\|cloudflare" --pretty=format:"%h %ad %s"

# Check for any recent changes in documentation or code related to D1
rg -i "d1.*support|cloudflare.*d1" --type md --type ts --type js

# Check Prisma's documentation or discussions about D1 support
rg -i "prisma.*d1|d1.*transaction"

#!/bin/bash
# Description: Check for recent issues or discussions about bcryptjs compatibility

# Test 1: Check for related issues
gh issue list --repo zenstackhq/zenstack --label "edge-runtime" --search "bcryptjs" --state all --limit 5

# Test 2: Check if the runtime package still depends on bcryptjs
rg -l "bcryptjs" "package.json"

#!/bin/bash
# Let's try a different approach to verify the bcryptjs usage and edge runtime compatibility

# Check for bcryptjs in all package.json files and package-lock.json
fd "package(-lock)?.json" --exec rg -l "bcryptjs" {}

# Search for bcryptjs related code or configuration
rg -i "bcryptjs" -A 3 -B 3

# Look for edge runtime related configurations
rg -i "edge.*runtime|edge.*function" -A 3 -B 3

#!/bin/bash
# Description: Check for any preview/experimental flags or recent issues related to edge runtime

# Test 1: Check for preview/experimental flags in code
rg -i "preview|experimental.*edge" 

# Test 2: Check recent edge-related issues
gh issue list --label "edge-runtime" --state all --limit 10

#!/bin/bash
# Let's try a different approach to verify edge runtime stability

# Check for any mentions of edge runtime being preview/experimental in docs
rg -i "preview.*edge|experimental.*edge" docs/

# Look for edge runtime related changes in recent commits
git log --grep="edge" --since="6 months ago" --pretty=format:"%h %s"

# Search for edge runtime implementation files
fd -t f -e ts -e js edge

# Check for any edge-related tests
fd -t f test.*edge

#!/bin/bash
# Let's check the content of the edge.md file and related documentation

# Check the full content of edge.md
cat docs/guides/edge.md

# Look for any edge-related files in the docs directory
fd . docs/ -t f -x grep -l "edge" {} \;

# Check package.json for edge-related dependencies and features
cat package.json | grep -i "edge"

docs/guides/typing-json.md (8)

6-16: Consider adding preview feature stability notice and migration guidance.

Since this is a preview feature, it would be helpful to:

1. Add a notice about potential breaking changes in future releases
2. Provide guidance on migrating existing untyped JSON fields to typed ones

---

22-50: Enhance type definition documentation.

Consider adding:

1. A list of supported field types (are all Prisma scalar types supported?)
2. Any constraints on field types (e.g., can arrays be used?)
3. Examples of unsupported type configurations

---

53-69: Clarify JSON field usage scenarios.

Please add information about:

1. Whether multiple JSON fields of the same type are allowed in a model
2. If JSON fields can be optional (e.g., profile Profile? @json)
3. Default value handling for JSON fields

---

70-124: Enhance PrismaClient integration examples.

Consider adding:

1. More complex query examples involving nested JSON fields
2. Examples of bulk operations (createMany, updateMany)
3. Performance implications of JSON field queries

🧰 Tools

🪛 LanguageTool

[style] ~121-~121: This expression usually appears with a “please” in front of it.
Context: ...lational field (which involves joins). [Let us know your thoughts](https://discord.gg/Ykhr7...

(INSERT_PLEASE)

---

121-121: Add "please" to the feedback request.

For better courtesy, revise to: "Please let us know your thoughts on this!"

🧰 Tools

🪛 LanguageTool

[style] ~121-~121: This expression usually appears with a “please” in front of it.
Context: ...lational field (which involves joins). [Let us know your thoughts](https://discord.gg/Ykhr7...

(INSERT_PLEASE)

---

125-171: Expand validation documentation.

Consider adding:

1. Complex validation scenarios (e.g., conditional validation)
2. Performance implications of validation on large JSON objects
3. Custom validation function examples

---

172-199: Add practical integration examples.

Consider adding:

1. Integration examples with popular form libraries (e.g., React Hook Form)
2. Custom Zod transformations for JSON fields
3. Error handling best practices

---

200-208: Enhance limitations section.

Consider adding:

1. Workarounds for current limitations where possible
2. Rough timeline estimates for addressing limitations
3. Any performance or scalability limitations

Configuration used: CodeRabbit UI
Review profile: CHILL

docs/the-complete-guide/part1/1-zmodel.md (1)

178-192: LGTM! Well-structured documentation about comments.

The added documentation tip effectively explains the different types of comments in ZModel and their purposes. The example is clear and demonstrates proper usage of documentation comments.

Consider adding a note about how documentation comments affect generated documentation artifacts (if any) beyond IDE tooltips.

docs/reference/cli.md (1)

161-161: Enhance documentation for the new --load-path option

The description for the new --load-path option could be more detailed to help users understand:

• What specific types of modules are loaded from this path
• Common scenarios where customizing this path would be useful
• How it interacts with the --prisma-client option

Consider expanding the description to something like:

-| --load-path <path> | Path to load modules generated by ZenStack. | "node_modules/.zenstack" |
+| --load-path <path> | Path to load ZenStack-generated modules (e.g., enhanced PrismaClient, policy handlers). Useful when using custom build output locations or monorepo setups. | "node_modules/.zenstack" |

docs/reference/zmodel-language.md (2)

699-706: Consider enhancing the @JSON attribute documentation.

While the documentation covers the basic functionality, it would be more helpful with:

1. A practical example showing usage
2. Details about type validation behavior

Consider adding:

 attribute @json()

Marks a field to be strong-typed JSON. The field's type must be a Type declaration.
+
+### Example
+```zmodel
+type Address {

• street String
• city String
• country String
  +}

+model User {

• id String @id
• address Address? @JSON
  +}
  +```

---

`1854-1885`: **Fix minor grammatical issue in the comments section.**

The section provides excellent documentation about different comment styles. There's a minor grammatical issue to fix.

Apply this change:

```diff
-You can also use JSDoc-style comments as documentation, however they are not passed along to the generated Prisma schema.
+You can also use JSDoc-style comments as documentation; however, they are not passed along to the generated Prisma schema.

🧰 Tools

🪛 LanguageTool

[typographical] ~1871-~1871: The word “however” is an adverb that can’t be used like a conjunction, and therefore needs to be separated from the sentence.
Context: ...se JSDoc-style comments as documentation, however they are not passed along to the genera...

(HOWEVER_SENTENCE)

Configuration used: CodeRabbit UI
Review profile: CHILL

docs/guides/typing-json.md (2)

10-16: Consider enhancing the transition between Prisma and ZenStack features.

While the introduction effectively explains JSON fields and their use cases, consider adding a brief sentence explaining what specific problems ZenStack solves compared to Prisma's basic JSON type support. This would help users better understand the value proposition.

 JSON fields provide great flexibility but at the cost of losing strong typing and validation. ZenStack's strongly typed JSON field feature helps you regain the lost benefits.
+For example, while Prisma only provides basic JSON type support, ZenStack adds TypeScript types, runtime validation, and enhanced developer experience.

---

202-211: Consider restructuring the limitations section.

The limitations section could be more structured to help users better understand the impact of each limitation. Consider:

1. Grouping limitations by their impact (e.g., type system limitations vs. runtime limitations)
2. Adding brief explanations of the implications of each limitation

 ## Limitations
 
 This feature is in preview and has the following limitations:
 
+### Type System Limitations
 1. Types cannot inherit from other types.
 1. Models cannot inherit from types.
 1. Types and abstract models are conceptually similar and they should probably be consolidated.
+
+### Runtime Limitations
 1. JSON field members cannot be used in access policies.
+
+### Impact and Workarounds
+- For type inheritance limitations, you can currently work around this by duplicating fields
+- For access policy limitations, consider storing sensitive data in regular columns instead of JSON fields
 
 We would like to continue gathering feedback and address these limitations in future releases.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~208-~208: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...abstract models are conceptually similar and they should probably be consolidated. 1...

(COMMA_COMPOUND_SENTENCE)

Configuration used: CodeRabbit UI
Review profile: CHILL